win: allow node.exe/iojs.exe to be renamed #599

piscisaureus · 2015-03-25T00:03:25Z

On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This makes it impossible to rename node.exe or iojs.exe, because when
that happens the module can't find its dependencies.

With this patch, a delay-load hook is added to all modules that are
compiled with node-gyp. The delay-load hook ensures that whenever a
module tries to load imports from node.exe/iojs.exe, it'll just refer
back to the process image, thus making it possible to rename the
iojs/node binary.

Bug: nodejs/node#751
Bug: nodejs/node#965
Downstream PR: nodejs/node#1251

TooTallNate · 2015-03-25T02:27:39Z

This seems fine to me (though I admit I don't really understand what the code itself is doing).

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This makes it impossible to rename node.exe or iojs.exe, because when that happens the module can't find its dependencies. With this patch, a delay-load hook is added to all modules that are compiled with node-gyp. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just refer back to the process image, thus making it possible to rename the iojs/node binary. Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]>

othiym23 · 2015-03-25T04:46:29Z

I need to know when this is merged / when a new version of node-gyp is released that incorporates this so I can pull it down and include it in npm, so I'm adding myself to this issue. 👼

bnoordhuis · 2015-03-25T16:21:49Z

addon.gypi

@@ -47,6 +50,15 @@
        # warning C4251: 'node::ObjectWrap::handle_' : class 'v8::Persistent<T>'
        # needs to have dll-interface to be used by clients of class 'node::ObjectWrap'
        'msvs_disabled_warnings': [ 4251 ],
+        # Set up delay-loading for node.exe/iojs.exe so the loadable module
+        # will still be able to find it's imports if the binary is renamed.


s/it's/its/

bnoordhuis · 2015-03-25T16:25:29Z

Clever. LGTM sans grammar nit.

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This makes it impossible to rename node.exe or iojs.exe, because when that happens the module can't find its dependencies. With this patch, a delay-load hook is added to all modules that are compiled with node-gyp. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just refer back to the process image, thus making it possible to rename the iojs/node binary. Bug: nodejs/node#751 Bug: nodejs/node#965 Downstream PR: nodejs/node#1251 PR-URL: nodejs#599 Reviewed-By: Ben Noordhuis <[email protected]>

piscisaureus · 2015-03-25T19:18:43Z

@justinmchase

I'm not sure this is going to work... it would be better to optionally link to node.lib or iojs.lib. I could be misunderstanding but, for example, we are actually running via http://nwjs.io which embeds io.js into the app but does not run the actual process iojs.exe, nor is that process even available at runtime.

Have you tried it? I think that this patch at best (or at worst) would have no effect.

justinmchase · 2015-03-25T22:21:49Z

@piscisaureus Sorry, I deleted the comment. I realized that you were actually probably talking about something else. There are a lot of threads on the forums here that I needed to read through. It seems like you guys have it under control and I look forward to getting the fix. I'm not blocked in the meantime.

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This makes it impossible to rename node.exe or iojs.exe, because when that happens the module can't find its dependencies. With this patch, a delay-load hook is added to all modules that are compiled with node-gyp. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just refer back to the process image, thus making it possible to rename the iojs/node binary. Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: #751 Bug: #965 Upstream PR: nodejs/node-gyp#599 PR-URL: #1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: #1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs/node#751 Bug: nodejs/node#965

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: #751 Bug: #965 Upstream PR: nodejs/node-gyp#599 PR-URL: #1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: #1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

win: allow node.exe/iojs.exe to be renamed

piscisaureus · 2015-04-16T18:15:53Z

@TooTallNate
FYI I'm looking at enabling the delay-load hook by default (making it opt-out instead of opt-in) in io.js 2.x (https://github.com/iojs/io.js/pull/1433/files).

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: #751 Bug: #965 Upstream PR: nodejs/node-gyp#599 PR-URL: #1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: #1266 Reviewed-By: Ben Noordhuis <[email protected]>

nodejs/node-gyp#599

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: #751 Bug: #965 Upstream PR: nodejs/node-gyp#599 PR-URL: #1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: #1266 Reviewed-By: Ben Noordhuis <[email protected]>

- use mongodb-js/node-gyp with nodejs/node-gyp#599 for proper windows 64bit support - get appveyor auto-deploying and testing for the full matrix https://ci.appveyor.com/project/imlucas/bson-ext/build/1.0.83

justinmchase · 2015-04-22T04:07:43Z

Can I still opt-out? The reason I ask is that it may break native modules in http://nwjs.io. I had to write my own delay load function that included nw.exe to get it to work and if you include it by default then it may be a problem.

If I can turn it off, or if it's possible to append entries to the delay load list in the gyp file then that would be fine.

piscisaureus · 2015-04-22T17:14:10Z

@justinmchase
With this patch, module authors have to opt-in (disabled by default). However in io.js 2.0 we may make it opt-out (iow, enabled by default).

The win_delay_load_hook gyp setting controls the behavior. See the commit message for more info: piscisaureus@52ceec3

I think it would be fine to replace the ".exe whitelist" by logic that enables the delay-load hook for any exe.

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

piscisaureus mentioned this pull request Mar 25, 2015

Windows: Broken node alias nodejs/node#751

Closed

piscisaureus mentioned this pull request Mar 25, 2015

node-gyp: allow node.exe/iojs.exe to be renamed nodejs/node#1251

Merged

piscisaureus force-pushed the fix-renaming branch from 147ca04 to 5c82901 Compare March 25, 2015 04:22

piscisaureus changed the title ~~win,node-gyp: allow node.exe/iojs.exe to be renamed~~ win: allow node.exe/iojs.exe to be renamed Mar 25, 2015

bnoordhuis reviewed Mar 25, 2015
View reviewed changes

piscisaureus force-pushed the fix-renaming branch 2 times, most recently from 2a69535 to 1670d26 Compare March 25, 2015 16:41

piscisaureus force-pushed the fix-renaming branch from d744e45 to 58949ca Compare March 26, 2015 05:05

piscisaureus force-pushed the fix-renaming branch from 58949ca to 52ceec3 Compare March 30, 2015 21:53

TooTallNate added a commit that referenced this pull request Apr 16, 2015

Merge pull request #599 from piscisaureus/fix-renaming

fbe8c26

win: allow node.exe/iojs.exe to be renamed

TooTallNate merged commit fbe8c26 into nodejs:master Apr 16, 2015

imlucas added a commit to imlucas/bson-ext that referenced this pull request Apr 17, 2015

debugging

2f32493

nodejs/node-gyp#599

am11 mentioned this pull request May 3, 2015

Create a troubleshooting guide sass/node-sass#921

Merged

imlucas mentioned this pull request May 6, 2015

Provide web accessible endpoint listing info on all releases electron/electron#1022

Closed

tvald mentioned this pull request Mar 16, 2017

don't delay loading node.exe due to imported data Venemo/node-lmdb#92

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

win: allow node.exe/iojs.exe to be renamed #599

win: allow node.exe/iojs.exe to be renamed #599

piscisaureus commented Mar 25, 2015

TooTallNate commented Mar 25, 2015

othiym23 commented Mar 25, 2015

bnoordhuis Mar 25, 2015

bnoordhuis commented Mar 25, 2015

piscisaureus commented Mar 25, 2015

justinmchase commented Mar 25, 2015

piscisaureus commented Apr 16, 2015

justinmchase commented Apr 22, 2015

piscisaureus commented Apr 22, 2015

win: allow node.exe/iojs.exe to be renamed #599

win: allow node.exe/iojs.exe to be renamed #599

Conversation

piscisaureus commented Mar 25, 2015

TooTallNate commented Mar 25, 2015

othiym23 commented Mar 25, 2015

bnoordhuis Mar 25, 2015

Choose a reason for hiding this comment

bnoordhuis commented Mar 25, 2015

piscisaureus commented Mar 25, 2015

justinmchase commented Mar 25, 2015

piscisaureus commented Apr 16, 2015

justinmchase commented Apr 22, 2015

piscisaureus commented Apr 22, 2015